Device state estimation under periodic motion

ABSTRACT

Systems, methods, apparatuses and computer-readable storage mediums are disclosed for device state estimation under periodic motion. In some implementations, a method comprises: detecting, by a device, periodic motion from a sensor signal generated by a sensor of the device; generating, by the device, a trigger signal or schedule based on the detecting; generating, by the device, a periodic motion constraint update in response to the detecting; and updating, by the device and in response to the trigger signal or schedule, an estimated state of the device using the periodic motion constraint update.

TECHNICAL FIELD

This disclosure relates generally to dead reckoning (DR) and devicestate estimation.

BACKGROUND

Computing an accurate radio navigation-based position solution inchallenging signal environments such as urban canyons and areas of densefoliage can be difficult. In these challenging signal environments,fewer signals are available, and those signals that are available tendto yield less accurate measurements on a device due to environmentalattenuation. One approach to improving the availability and quality ofposition solutions in challenging signal environments is to combineobservations of radio navigation signals with input from other sensorsor signals that measure some aspect of user or antenna motion between orduring the measurement of radio navigation signals. The additionalinformation improves the position solution by subtracting out antennamotion between epochs of radio navigation measurements, effectivelyallowing multiple epochs of measurements to be statistically combined toreduce error.

One approach to improving the availability and quality of positionsolutions blends measurements of radio navigation signals in a KansanFilter with numerical integration of accelerometer and/or rate gyroscopemeasurements or the like to correct for antenna motion between epochs.For this approach, the numerical integration component is often calledan inertial navigation system (BINS) or DR component. In this approach,the DR component is used to subtract antenna motion between epochs somultiple epochs of radio navigation measurements may be combined.However, because the DR component estimates motion from one epoch to thenext, the DR component accumulates errors over time as that motion iscombined over multiple epochs.

It is desirable to minimize accumulated motion errors by making the DRcomponent more stable. This can be done by introducing motionconstraints such as, for example, directions in which motion cannotoccur or directions in which motion is limited. For pedestrians, forexample, a step counting model may be used to limit distance traveled. Achallenge of applying motion constraints is deciding when to apply theconstraints. For example, a pedestrian step counting motion constraintmay harm, rather than help a positioning solution if the step constraintis applied at times that do not correspond to steps. Applying the stepconstraint at times that correspond to steps is a challenging task,however, because motion varies widely from user to user. For example,some users step with their heels, while other users step with the padsof their feet. Further, that motion appears differently in sensors in adevice held in a hand versus carried in, for example, a pocket orhandbag. Thus timing the application of DR constraints is both difficultand critical to performance.

SUMMARY

Systems, methods, apparatuses and non-transitory, computer-readablestorage mediums are disclosed for device state estimation under periodicmotion.

In some implementations, a method comprises: detecting, by a device,periodic motion from a sensor signal generated by a sensor of thedevice; generating, by the device, a trigger signal or schedule based onthe detecting; generating, by the device, a periodic motion constraintupdate in response to the detecting; and updating, by the device and inresponse to the trigger signal or schedule, an estimated state of thedevice using the periodic motion constraint update.

In some implementations, a device comprises: one or more sensors; one ormore processors; memory coupled to the one or more processors andconfigured to store instructions, which, when executed by the one ormore processors, causes the one or more processors to perform operationscomprising: detecting periodic motion from a sensor signal generated bythe one or more sensors; generating a trigger signal or schedule basedon the detecting; generating a periodic motion constraint update inresponse to the detecting; and responsive to the trigger signal orschedule, updating an estimated state of the device using the periodicmotion constraint update.

Particular implementations disclosed herein provide one or more of thefollowing advantages. A periodicity feature detected in a sensor signalis used to generate a trigger signal or schedule for a periodic motionconstraint update to a device state estimator. The periodic motionconstraint update results in a DR component that is more accurate, whichin turn results in a more accurate device state estimate (e.g.,position, velocity).

The details of the disclosed implementations are set forth in theaccompanying drawings and the description below. Other features, objectsand advantages are apparent from the description, drawings and claims.

DESCRIPTION OF DRAWINGS

FIG. 1 illustrates periodic motion of a hand held device, according toan implementation.

FIG. 2 is a block diagram of an example system for estimating devicestate, according to an implementation.

FIG. 3 is a block diagram of the example update detector shown in FIG.2, according to an implementation.

FIG. 4 is a block diagram of the example update generator shown in FIG.2, according to an implementation.

FIG. 5 is a block diagram of the example predictor shown in FIG. 2,according to an implementation.

FIG. 6 is a flow diagram of an example process for device stateestimation under periodic motion, according to an implementation.

FIG. 7 is a block diagram of example device architecture forimplementing the features and processes described in reference to FIGS.1-6.

The same reference symbol used in various drawings indicates likeelements.

DETAILED DESCRIPTION

The implementations disclosed herein begin with the observation thatmotion constraints applied once per motion period yield a significantimprovement to the stability of a DR component, because the user, deviceand antenna are in nearly the same configuration from one point in themotion cycle to the same point in the next motion cycle. Mostimportantly, so long as the motion is periodic, signal processingtechniques can be used to detect and track a periodicity feature in asensor signal regardless of the actual shape or magnitude of the sensorsignal. Follow-on techniques can then be used to identify portions ofthe motion cycle that are safe for applying a pedestrian periodic motionconstraint update to a device state estimator, resulting in a DRcomponent with significantly improved stability during periodic motion.This technique is particularly useful for pedestrian motion (e.g., pedalmotion due to repeated footfalls), which is necessarily periodicregardless of how the user steps or carries his or her device. Thedisclosed implementations, however, also apply to all kinds of periodicmotion, including pedestrian (e.g. Walking, running) and non-pedestrianmodes of transport (e.g., cycling, horseback riding, scooter riding,roller-skating).

FIG. 1 illustrates periodic motion of a hand-held device, according toan implementation. In the example shown mobile device 102 (e.g., a smartphone, wrist watch) is held or worn by user 100. The magnitude ormodulus of an acceleration signal provided by accelerometer of mobiledevice 102 tends to be periodic when user 100 walks with mobile device102 in hand because walking is a fundamentally periodic activity. Ifuser 100 is swinging her arm along arm swing path 104, an interestingperiodicity feature is the local minimum acceleration magnitude, wheremobile device 102 is undergoing the least acceleration of the entiremotion cycle. The local minimum acceleration magnitude occurs twice perarm swing motion: once when the arm swings to apex 106 in front of user100 and once when the arm of user 100 swings to apex 108 behind user100. At apexes 106, 108 (the terminus points of arm swing path 104), theestimated speed of the device will be approximately equal to the speedof the user's body. Accordingly, the times when apexes 106, 108 of armswing path 104 are reached provide desirable times to apply pedestrianmotion constraints (e.g., stride length) or device orientationconstraints because small errors in predicting at this time do notresult in significant changes of device orientation or motion. Thisyields a more stable DR component for pedestrian motion, resulting insignificant improvement to the device state estimation.

Example System

FIG. 2 is a block diagram of an example system for estimating devicestate, according to an implementation. In this example implementation,system 200 can include sensors 202, update detector 204, updategenerator 206, predictor 208 and initializer 210.

Sensors 202 can include accelerometer, rate gyroscopes, barometers,magnetometer and the like. Sensors 202 provide sensor signals to updatedetector 204 and update generator 206. Update detector 204 detects andtracks periodicity in the sensor signals and triggers or schedulespedestrian periodic motion constraint updates in predictor 208, asdescribed in reference to FIG. 3. Update generator 206 providesparameters to predictor 208 that are needed to apply pedestrian periodicconstraint updates, and also provides observable inputs for device stateupdates, as described in reference to FIG. 4.

Initializer 210 provides initialization data to predictor 208 to ensurea good initial condition within a liberalization boundary of a correctsolution. In some implementations, position and velocity measurementsfrom Global Navigation Satellite System (GNUS) and/or Wife access point(GAP) data can be used to generate initial conditions for position andvelocity. An initial condition for device orientation or attitude can bederived by least squares fitting a device attitude quatrain to referencevector observations using, for example, a Wahba problem solver, such asthe well-known q-method. The q-method can use a variety of referencevector observations in Earth-fixed and device-fixed reference frames andgenerate, for example, an Earth-Centered-Earth-Fixed (ECEF) to devicequaternion or rotation matrix (e.g., direction cosine matrix). Someexample measurements/models include but are not limited to: Earthgravity model (Earth-fixed), gravity vector from accelerometer(device-fixed), GNSS data (Earth-fixed), principal components ofaccelerometer data (device-fixed), International Geographic ReferenceField (IGRF) data (Earth-fixed) and magnetometer data (device-fixed).

In some implementations, predictor 208 generates an estimate of a devicestate, including XYZ device position, XYZ device velocity, deviceattitude using a 4-element quaternion, XYZ device rate gyro biases andXYZ device accelerometer biases. These 16 states can be estimated using,for example, a Kalman Filter formulation, which is updated with periodicmotion constraint updates, as described in reference to FIGS. 4-6.

FIG. 3 is a block diagram of the example update detector 204 shown inFIG. 2, according to an implementation. In this example implementation,the sensor signal is an acceleration vector provided by a three-axisaccelerometer. Other sensor signals can also be used such as a rategyroscope signal, which can, for example, be used to determine theperiodic rotation of the arm.

In some implementations, update detector 204 can include periodicitydetector 301, fundamental motion frequency estimator 302, periodicityextractor 304 and scheduler 308. Periodicity detector 301 receives oneor more sensor signals and step cadence frequencies. For example,detector 301 can receive an acceleration vector or magnitude. If anacceleration vector is provided detector 301 can calculate the norm ofthe vector to obtain the magnitude or modulus. In some implementations,detector 301 can pre-process the sensor signal by applying a low pass orband pass filter to remove unwanted frequencies outside the range offrequencies of interest determined by the step cadence frequencies(e.g., 0.45-3.15 Hz). In some implementations, a moving average ormedian filter can be applied to the sensor signals. In otherimplementations, a non-causal finite-window Gaussian filter can beapplied to the sensor signals.

In some implementations, detector 301 can include a sliding windowfrequency transform (e.g., Discrete Fourier Transform (DFT)) that isapplied to a set of samples of the sensor signal to detect periodicityin the sensor signal. Frequency data generated by detector 301 isprovided to fundamental motion frequency estimator 302, which determinesthe instantaneous fundamental motion frequency of the sensor signal. Forexample, if the length of the sliding window used in detector 301 is atleast as long as several fundamental periods of the user's arm swing,the lowest statistically non-zero frequency bin output by the frequencytransform can be selected as the fundamental motion frequency. In someimplementations, an instantaneous fundamental motion frequency can alsobe determined as a weighted average over significantly non-zero binfrequencies. In some implementations, the frequency transform can beimplemented using a Fast Fourier Transform (FFT).

The instantaneous fundamental motion frequency can be provided as inputto periodicity feature extractor 304, which extracts a periodicityfeature from one or more segments of the sensor signal that are eachapproximately equal in duration to the fundamental motion period of theobserved periodic sensor signal. In this example, where the sensorsignal is the acceleration magnitude, the periodicity feature is thelocal minimum acceleration magnitude. The local minimum accelerationmagnitude occurs at apexes 106, 108, as described in reference toFIG. 1. If the fundamental motion frequency is f_(s), then thefundamental period of the signal is T_(s)=1/f_(s) and the local minimumacceleration magnitude occurs every T_(s) seconds. There can be a numberof local acceleration minima. For example, a pedestrian with a deviceswinging in his hand tends to reach a local acceleration minimum eachtime one of the user's feet is as far off the ground as possible.Sometimes the strongest frequency is the user's step frequency (e.g.,the frequency of the user's footfalls) and sometimes it is the user'sgait frequency (e.g., the frequency of the user's left footfalls).

In some implementations, the observed periodic signal (e.g.,acceleration magnitude) need not be periodic at all times and thefundamental motion frequency may change over time. In these cases, aphase tracking algorithm (e.g., a phase-locked loop (PLL), delay-lockedloop (DLL), Kalman Filter) can use the fundamental motion frequency totrack the phase of the sensor signal so that the periodicity feature canbe extracted from the sensor signal.

Scheduler 303 is informed each time the periodicity feature is extractedfrom the sensor signal. Scheduler 303 is configured to send a periodicmotion detection (PMD) signal to update generator 206 and predictor 208.The PMD signal can be a trigger signal and/or a schedule (e.g., apredicted time of the next periodicity feature extraction). For example,with knowledge of the most recent arm swing apex and the fundamentalmotion frequency (arm swing motion frequency), the time of the next apexcan be predicted and used to schedule pedestrian periodic motionconstraint updates. Accordingly, pedestrian periodic motion updates canbe generated by update generator 206 and applied by predictor 208 eachtime the arm reaches an apex. At each apex 106, 108, the rotationalaccelerations are substantially zero and the linear velocity of the bodyof user 100 becomes the dominant force detected by the accelerometers.Therefore, the PMD signal indicates an optimum time to apply pedestrianperiodic motion constraints to ensure that the pedestrian periodicmotion constraint updates will not introduce unintended error into theestimated device state provided by predictor 208.

FIG. 4 is a block diagram of the example update generator 206 shown inFIG. 2, according to an implementation. In this example implementation,update generator 206 can include update selector 401, pedometer 402,coordinate transform 403, gravity corrector 404, integrators 405, 406and PCA module 407.

In some implementations, pedometer 402 receives an acceleration datavector from 3-axis accelerometers. The norm of the acceleration vector<a_(x), a_(y), a_(z)> can be calculated to generate an accelerationmodulus or magnitude. For example, the magnitude a_(mag) of anacceleration vector {right arrow over (a)}=<a_(x), a_(y), a_(z)>provided by a 3-axis (x, y, z axes) accelerometer is given by,a _(mag)=|{right arrow over (a)}|=√{square root over (a _(x) ² a _(x) ²+a _(z) ².)}  [1]

The acceleration magnitude can be used by pedometer 402 to determineuser step frequency and speed s, as described in, for example, U.S.Patent Publication No. US 2013/0085677A1, for “Techniques for ImprovedPedometer Readings,” filed Sep. 30, 2011, which patent publication isincorporated by reference herein in its entirety. In someimplementations, a device rotation rate vector <ω_(x), ω_(y), ω_(z)>from a 3-axis rate gyroscope on the device can be input to pedometer402. The device rotation rate vector <ω_(x), ω_(y), ω_(z)> can be used,for example, in step detection in addition to the acceleration vector.

In some implementations, update generator 206 sends pedestrian periodicmotion constraint updates to predictor 208 at a specified frequency(e.g., 1 Hz) or when no periodic motion is detected, as determined by,for example, the PMD signal provided by update detector 204. Forexample, if no periodic motion is detected, then updates can include achange in altitude Δh across a set period of time (e.g., a user gaitperiod). The change in altitude can be determined by a change inbarometric pressure determined by a barometer sensor. The change invelocity Δv can be calculated from the acceleration vector after theacceleration vector has been transformed from device coordinates toreference coordinates by coordinate transform 403, corrected for gravityby gravity corrector 404 and integrated over the last set period of timeby integrator 405. In some implementations, coordinate transformation403 is implemented by a quaternion using techniques known in the art.

In some implementations, update generator 206 sends pedestrian periodicmotion constraint updates to predictor 208 at a specified frequency(e.g., 1 Hz) or when periodic motion is detected, as determined by, forexample, the PMD signal provided by update detector 204. For example, ifperiodic motion is detected, then pedestrian periodic motion constraintupdates include a change in horizontal position Δx across the specifiedtime period, a change in altitude Δh across the specified time period, achange in velocity Δv across the specified time period and a primarydirection ψ of user motion across the specified time period. The primarydirection ψ of user travel can be generated by, for example, PCA module407 using principal component analysis on the acceleration vector.

For example, accelerometers on the device can report accelerations thatare a function of user acceleration, gravity, some minor effects (e.g.,centripetal and Coriolis acceleration due to the rotation of the Earth)and noise. In some implementations, a set of acceleration measurementscan be used to determine a direction of travel by: 1) collecting a setof device acceleration measurements over a specified time interval(e.g., a pre-set time window or the last step period or the last gaitperiod); 2) determining the sum of nearly-constant externalaccelerations (gravity, centripetal, Coriolis) by, e.g., averagingacceleration measurements over several periods; 3) removing thenearly-constant external accelerations by subtracting them from eachmeasurement; 4) computing the sample covariance for the residualgravity-subtracted accelerations computed in step 3; and 5) computing asingular value decomposition of the sample covariance computed in step4. The singular vector with the largest corresponding singular value isthe direction of greatest non-gravity acceleration over the period andis a good measurement of user direction of travel.

In some implementations, Δx can be generated by integrating an averageuser speed determined by pedometer 402. The average user speed can bedetermined by, for example, multiplying an average step frequency by thestride length of the user.

In some implementations, update selector 401 implements a softwareswitch that selects the appropriate motion constraint updates to send topredictor 208 based on the PMD signal received from update detector 204.

FIG. 5 is a block diagram of the example predictor 208 shown in FIG. 2,according to an implementation. In this example implementation,predictor 208 can include acceleration model 502, estimator 504 andinitializer 210.

In some implementations, user acceleration model 502 implements apath-coordinate formulation for user acceleration given by,

=s·(

_(user)×

_(v))+{dot over (s)}·

_(v),  [2]where s is the speed of the user,

$\overset{.}{s} = \frac{d\; s}{d\; t}$is the rate of change of user speed,

is the rotation rate of the user and

is a unit tangent vector to a path that the user is traveling along. Theuser rotation rate vector

can be derived from the device rotation rate {right arrow over(ω)}_(device), which can be obtained from rate gyroscopes on the device.The unit tangent vector

_(v) and user speed s can be obtained from estimator 504. The useracceleration

can be used as an input to estimator 504, where

$\overset{.}{s} = \frac{d\; s}{d\; t}$can be driven by a small white noise process. The user accelerationdetermined by equation [2] can be input into estimator 504 as an updateto, for example, correct for antenna motion between measurement timeepochs. In one implementation, the acceleration in equation [2] is inputto a numerical integrator to predict how the user has moved from onemeasurement time epoch to the next. In one implementation, this isimplemented as part of the prediction step of estimator 504.

For typical hand held device use cases, including, for example, driving,walking while looking at the device screen and walking with the devicein a back pocket are all cases in which the device and the user movetogether rigidly. When the user and device share an approximately rigidconnection, the human preference for low acceleration puts limits on therate of change of user speed

$\overset{.}{s} = {\frac{d\; s}{d\; t}.}$For example, in many use cases where a device-fixed assumption holds,

${\overset{.}{s} = {\frac{d\; s}{d\; t} \approx 0}},$If

${\overset{.}{s} = {\frac{d\; s}{d\; t} \approx 0}},$all of the user motion can be predicted with just the user rotation rate

, which yields significant improvements in the DR component performanceover 6 degrees of freedom (6-DOF) formulations that require lessaccurate accelerometers. The path-coordinate formulation of equation [2]also yields significant improvements in DR component performance overconstant velocity models, which cannot predict changes in direction.

In some implementations, estimator 504 is implemented as a KalmanFilter. The state vector can include xyz device position in referencecoordinates, xyz device velocity in reference coordinates, deviceattitude using a 4-element quaternion describing device rotation fromreference coordinate axes to device coordinate axes, xyz device rategyro biases and xyz device accelerometer biases. In someimplementations, the observables can include GNSS and WiFi data. GNSSdata (e.g., latitude, longitude) can include data from any GNSSincluding but not limited to the Global Position System (GPS). WiFi datacan be provided by a positioning service that provides AP data (e.g.,locations of beacons, routers).

An example Kalman Filter that uses GNSS and WiFi observables and motioncontext is described in U.S. Pat. No. 8,615,253 for “State EstimationUsing Motion Context and Multiple Observation Types,” issued Dec. 24,2013, which patent is incorporated by reference herein in its entirety.In some implementations, the position states are represented in ageodetic coordinate frame and the velocity states are represented in ageodetic, local-level coordinate frame, such as North-East-Up (NEU).Accordingly, in some implementations pedestrian periodic motionconstraint updates may have to be transformed into a different referencecoordinate frame before they can be applied in the estimator 504.

In some implementations, constraints are incorporated into the Kalmanfilter as measurement updates of the form 0=h(x)+w, where x is thecurrent state estimate, h(x) is the possibly-nonlinear function thatdescribes the constraint space and w is the tolerance variable whosenoise statistics (e.g., measurement noise covariance matrix R) describethe statistical degree to which constraint violation is tolerated. Forexample, to constrain vertical velocity to zero, h(x) would be afunction that projects the current velocity estimate onto the localvertical direction and the square root of the diagonal of the R matrixwould be the expected 1-sigma violation of that constraint. Otherconstraint types would have different h(x) functions and different Rvalues.

In some implementations, the path-coordinate acceleration of equation[2] is used as part of the prediction step of the Kalman filter. Duringa prediction step, the acceleration is input to a numerical integratorto describe the change in the velocity and position estimates from onetime to the next. As such, the process noise matrix Q can be set withnoise parameters for the path-coordinate acceleration model, which mightinclude, for example, noise terms that describe rate gyro andaccelerometer measurement noise and also typical statistics for changesin user speed.

Example Process

FIG. 6 is a flow diagram of an example process 600 for device stateestimation under periodic motion, according to an implementation.Process 600 can be implemented by mobile device architecture 700, asdescribed in reference to FIG. 7.

In some implementations, process 600 can begin by detecting aperiodicity feature from a sensor signal (602) and generating a triggersignal or schedule based on the periodicity feature (604). For example,each time a periodicity feature (e.g., a time of local minimumacceleration magnitude) is detected from a windowed sensor signal basedon a fundamental motion frequency a trigger signal or schedule isgenerated, as described in reference to FIG. 3.

Process 600 can continue by generating a periodic motion constraintupdate in response to the trigger signal or schedule (606). For example,a different set of parameters and/or observables can be used to update apredictor based on whether or not periodic motion is detected, asdescribed in reference to FIG. 4.

Process 600 can continue by applying the periodic motion constraintupdate to the predictor in response to the trigger signal or schedule(608). For example, the predictor can include an extended Kalman Filter,and the updates can be applied as Kalman updates, as described inreference to FIG. 5. Some examples of measurement updates that can beincluded in one or more measurement vectors of a Kalman filter,depending on availability and whether periodicity was detected, includebut are not limited to: GNSS-based position, GNSS-based velocity,WiFi-based position, distance traveled constraint over the past stepperiod, direction of travel over the past step period and change invelocity over the past step period.

Example Device Architecture

FIG. 7 is a block diagram of example device architecture 700 forimplementing the features and processes described in reference to FIGS.1-6. Architecture 700 may be implemented in any mobile device forgenerating the features and processes described in reference to FIGS.1-6, including but not limited to smart phones and wearable computers(e.g., smart watches, fitness bands). Architecture 700 may includememory interface 702, data processor(s), image processor(s) or centralprocessing unit(s) 704, and peripherals interface 706. Memory interface702, processor(s) 704 or peripherals interface 706 may be separatecomponents or may be integrated in one or more integrated circuits. Oneor more communication buses or signal lines may couple the variouscomponents.

Sensors, devices, and subsystems may be coupled to peripherals interface706 to facilitate multiple functionalities. For example, motion sensor710, light sensor 712, and proximity sensor 714 may be coupled toperipherals interface 706 to facilitate orientation, lighting, andproximity functions of the device. For example, in some implementations,light sensor 712 may be utilized to facilitate adjusting the brightnessof touch surface 746. In some implementations, motion sensor 710 (e.g.,an accelerometer, rate gyroscope) may be utilized to detect movement andorientation of the device. Accordingly, display objects or media may bepresented according to a detected orientation (e.g., portrait orlandscape).

Other sensors may also be connected to peripherals interface 706, suchas a temperature sensor, a barometer, a biometric sensor, or othersensing device, to facilitate related functionalities. For example, abiometric sensor can detect fingerprints and monitor heart rate andother fitness parameters.

Location processor 715 (e.g., GNSS receiver chip) may be connected toperipherals interface 706 to provide geo-referencing. Electronicmagnetometer 716 (e.g., an integrated circuit chip) may also beconnected to peripherals interface 706 to provide data that may be usedto determine the direction of magnetic North. Thus, electronicmagnetometer 716 may be used as an electronic compass.

Camera subsystem 720 and an optical sensor 722, e.g., a charged coupleddevice (CCD) or a complementary metal-oxide semiconductor (CMOS) opticalsensor, may be utilized to facilitate camera functions, such asrecording photographs and video clips.

Communication functions may be facilitated through one or morecommunication subsystems 724. Communication subsystem(s) 724 may includeone or more wireless communication subsystems. Wireless communicationsubsystems 724 may include radio frequency receivers and transmittersand/or optical (e.g., infrared) receivers and transmitters. Wiredcommunication systems may include a port device, e.g., a UniversalSerial Bus (USB) port or some other wired port connection that may beused to establish a wired connection to other computing devices, such asother communication devices, network access devices, a personalcomputer, a printer, a display screen, or other processing devicescapable of receiving or transmitting data.

The specific design and implementation of the communication subsystem724 may depend on the communication network(s) or medium(s) over whichthe device is intended to operate. For example, a device may includewireless communication subsystems designed to operate over a globalsystem for mobile communications (GSM) network, a GPRS network, anenhanced data GSM environment (EDGE) network, IEEE802.xx communicationnetworks (e.g., Wi-Fi, Wi-Max, ZigBee™), 3G, 4G, 4G LTE, code divisionmultiple access (CDMA) networks, near field communication (NFC), Wi-FiDirect and a Bluetooth™ network. Wireless communication subsystems 724may include hosting protocols such that the device may be configured asa base station for other wireless devices. As another example, thecommunication subsystems may allow the device to synchronize with a hostdevice using one or more protocols or communication technologies, suchas, for example, TCP/IP protocol, HTTP protocol, UDP protocol, ICMPprotocol, POP protocol, FTP protocol, IMAP protocol, DCOM protocol, DDEprotocol, SOAP protocol, HTTP Live Streaming, MPEG Dash and any otherknown communication protocol or technology.

Audio subsystem 726 may be coupled to a speaker 728 and one or moremicrophones 730 to facilitate voice-enabled functions, such as voicerecognition, voice replication, digital recording, and telephonyfunctions.

I/O subsystem 740 may include touch controller 742 and/or other inputcontroller(s) 744. Touch controller 742 may be coupled to a touchsurface 746. Touch surface 746 and touch controller 742 may, forexample, detect contact and movement or break thereof using any of anumber of touch sensitivity technologies, including but not limited to,capacitive, resistive, infrared, and surface acoustic wave technologies,as well as other proximity sensor arrays or other elements fordetermining one or more points of contact with touch surface 746. In oneimplementation, touch surface 746 may display virtual or soft buttonsand a virtual keyboard, which may be used as an input/output device bythe user.

Other input controller(s) 744 may be coupled to other input/controldevices 748, such as one or more buttons, rocker switches, thumb-wheel,infrared port, USB port, and/or a pointer device such as a stylus. Theone or more buttons (not shown) may include an up/down button for volumecontrol of speaker 728 and/or microphone 730.

In some implementations, architecture 700 may present recorded audioand/or video files, such as MP3, AAC, and MPEG video files. In someimplementations, device 700 may include the functionality of an MP3player and may include a pin connector for tethering to other devices.Other input/output and control devices may be used.

Memory interface 702 may be coupled to memory 750. Memory 750 mayinclude high-speed random access memory or non-volatile memory, such asone or more magnetic disk storage devices, one or more optical storagedevices, or flash memory (e.g., NAND, NOR). Memory 750 may storeoperating system 752, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS,or an embedded operating system such as VxWorks. Operating system 752may include instructions for handling basic system services and forperforming hardware dependent tasks. In some implementations, operatingsystem 752 may include a kernel (e.g., UNIX kernel).

Memory 750 may also store communication instructions 754 to facilitatecommunicating with one or more additional devices, one or more computersor servers, including peer-to-peer communications. Communicationinstructions 754 may also be used to select an operational mode orcommunication medium for use by the device, based on a geographiclocation (obtained by the GPS/Navigation instructions 768) of thedevice.

Memory 750 may include graphical user interface instructions 756 tofacilitate graphic user interface processing, including a touch modelfor interpreting touch inputs and gestures; sensor processinginstructions 758 to facilitate sensor-related processing and functions;phone instructions 760 to facilitate phone-related processes andfunctions; electronic messaging instructions 762 to facilitateelectronic-messaging related processes and functions; web browsinginstructions 764 to facilitate web browsing-related processes andfunctions; media processing instructions 766 to facilitate mediaprocessing-related processes and functions; GPS/Navigation instructions768 to facilitate GPS and navigation-related processes; camerainstructions 770 to facilitate camera-related processes and functions;and other instructions 772 for performing some or all of the featuresand processes, as described in reference to FIGS. 1-6.

Each of the above identified instructions and applications maycorrespond to a set of instructions for performing one or more functionsdescribed above. These instructions need not be implemented as separatesoftware programs, procedures, or modules. Memory 750 may includeadditional instructions or fewer instructions. Furthermore, variousfunctions of the device may be implemented in hardware and/or insoftware, including in one or more signal processing and/or applicationspecific integrated circuits (ASICs).

The features described may be implemented in digital electroniccircuitry or in computer hardware, firmware, software, or incombinations of them. The features may be implemented in a computerprogram product tangibly embodied in an information carrier, e.g., in amachine-readable storage device, for execution by a programmableprocessor; and method steps may be performed by a programmable processorexecuting a program of instructions to perform functions of thedescribed implementations by operating on input data and generatingoutput.

The described features may be implemented advantageously in one or morecomputer programs that are executable on a programmable system includingat least one programmable processor coupled to receive data andinstructions from, and to transmit data and instructions to, a datastorage system, at least one input device, and at least one outputdevice. A computer program is a set of instructions that may be used,directly or indirectly, in a computer to perform a certain activity orbring about a certain result. A computer program may be written in anyform of programming language (e.g., Objective-C, Java), includingcompiled or interpreted languages, and it may be deployed in any form,including as a stand-alone program or as a module, component,subroutine, or other unit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors orcores, of any kind of computer. Generally, a processor will receiveinstructions and data from a read-only memory or a random access memoryor both. The essential elements of a computer are a processor forexecuting instructions and one or more memories for storing instructionsand data. Generally, a computer may communicate with mass storagedevices for storing data files. These mass storage devices may includemagnetic disks, such as internal hard disks and removable disks;magneto-optical disks; and optical disks. Storage devices suitable fortangibly embodying computer program instructions and data include allforms of non-volatile memory, including by way of example, semiconductormemory devices, such as EPROM, EEPROM, and flash memory devices;magnetic disks such as internal hard disks and removable disks;magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor andthe memory may be supplemented by, or incorporated in, ASICs(application-specific integrated circuits). To provide for interactionwith a user the features may be implemented on a computer having adisplay device such as a CRT (cathode ray tube), LED (light emittingdiode) or LCD (liquid crystal display) display or monitor for displayinginformation to the author, a keyboard and a pointing device, such as amouse or a trackball by which the author may provide input to thecomputer.

One or more features or steps of the disclosed embodiments may beimplemented using an Application Programming Interface (API). An API maydefine on or more parameters that are passed between a callingapplication and other software code (e.g., an operating system, libraryroutine, function) that provides a service, that provides data, or thatperforms an operation or a computation. The API may be implemented asone or more calls in program code that send or receive one or moreparameters through a parameter list or other structure based on a callconvention defined in an API specification document. A parameter may bea constant, a key, a data structure, an object, an object class, avariable, a data type, a pointer, an array, a list, or another call. APIcalls and parameters may be implemented in any programming language. Theprogramming language may define the vocabulary and calling conventionthat a programmer will employ to access functions supporting the API. Insome implementations, an API call may report to an application thecapabilities of a device running the application, such as inputcapability, output capability, processing capability, power capability,communications capability, etc.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made. Elements of one ormore implementations may be combined, deleted, modified, or supplementedto form further implementations. In yet another example, the logic flowsdepicted in the figures do not require the particular order shown, orsequential order, to achieve desirable results. In addition, other stepsmay be provided, or steps may be eliminated, from the described flows,and other components may be added to, or removed from, the describedsystems. Accordingly, other implementations are within the scope of thefollowing claims.

What is claimed is:
 1. A method comprising: detecting, by a locationprocessor of a device, periodic motion from a sensor signal generated bya sensor of the device; generating, by the location processor of thedevice, a trigger signal or schedule based on the detecting; generating,by the location processor of the device, a periodic motion constraintupdate in response to the detecting; and updating, by the locationprocessor of the device and in response to the trigger signal orschedule, a predicted position or velocity of the device.
 2. The methodof claim 1, wherein detecting periodic motion from the sensor signalfurther comprises: applying a sliding window frequency transform to thesensor signal to determine a fundamental motion frequency.
 3. The methodof claim 2, wherein generating the trigger signal or schedule based onthe detecting further comprises: extracting, by the location processorof the device, a periodicity feature from the sensor signal based on thefundamental motion frequency; and generating the trigger signal orschedule based on the extracted periodicity feature.
 4. The method ofclaim 3, wherein the sensor signal is acceleration magnitude and theperiodicity feature is a local acceleration magnitude minimum.
 5. Themethod of claim 1, wherein applying the update to a predicted positionor velocity of the device in response to the trigger signal or scheduleincludes updating a Kalman filter prediction with the update.
 6. Themethod of claim 1, wherein the periodic motion constraint updateincludes a change in device horizontal position across a time period. 7.The method of claim 1, wherein the periodic motion constraint updateincludes a change in device altitude across a time period.
 8. The methodof claim 1, wherein the periodic motion constraint update includes achange of device velocity across a time period.
 9. The method of claim1, wherein the periodic motion constraint update includes a primarydirection of device motion across a time period.
 10. A devicecomprising: one or more sensors; a location processor; memory coupled tothe location processor and configured to store instructions that whenexecuted by the location processor cause the location processor toperform operations comprising: detecting, by the location processor,periodic motion from a sensor signal generated by the one or moresensors; generating, by the location processor, a trigger signal orschedule based on the detecting; generating, by the location processor,a periodic motion constraint update in response to the detecting; andresponsive to the trigger signal or schedule, updating, by the locationprocessor, a predicted position or velocity of the device.
 11. Thedevice of claim 10, wherein detecting periodic motion from the sensorsignal further comprises: applying a sliding window frequency transformto the sensor signal to determine a fundamental motion frequency. 12.The device of claim 11, wherein generating the trigger signal orschedule based on the detecting further comprises: extracting aperiodicity feature from the sensor signal based on the fundamentalmotion frequency; and generating the signal or schedule based on theextracted periodicity feature.
 13. The device of claim 12, wherein thesensor signal is acceleration magnitude and the periodicity feature is alocal acceleration magnitude minimum.
 14. The device of claim 10,wherein applying the update to a predicted position or velocity of thedevice in response to the trigger signal or schedule includes updating aKalman filter prediction with the update.
 15. The device of claim 10,wherein the periodic motion constraint update includes a change indevice horizontal position across a time period.
 16. The device of claim10, wherein the periodic motion constraint update includes a change indevice altitude across a last time period.
 17. The device of claim 10,wherein the periodic motion constraint update includes a change ofdevice velocity across a last time period.
 18. The device of claim 10,wherein the periodic motion constraint update includes a primarydirection of device motion across a last time period.